Template talk:IsLeapYear

Samples

Edit this section and view the source for details of use.

This year (2024) is a leap year!

Legacy Code

{{#expr:((({{{1|{{CURRENTYEAR}}}}} mod 4) = 0) and (({{{1|{{CURRENTYEAR}}}}} mod 100) <> 0)) or ((({{{1|{{CURRENTYEAR}}}}} mod 100) = 0) and (({{{1|{{CURRENTYEAR}}}}} mod 400) = 0))}}

Test data

1600 1 (should equal 1)
1700 0 (should equal 0)
1800 0 (should equal 0)
1900 0 (should equal 0)
1990 0 (should equal 0)
1991 0 (should equal 0)
1992 1 (should equal 1)
1993 0 (should equal 0)
1994 0 (should equal 0)
1995 0 (should equal 0)
1996 1 (should equal 1)
1997 0 (should equal 0)
1998 0 (should equal 0)
1999 0 (should equal 0)
2000 1 (should equal 1)
2001 0 (should equal 0)
2002 0 (should equal 0)
2003 0 (should equal 0)
2004 1 (should equal 1)
2005 0 (should equal 0)
2006 0 (should equal 0)
2007 0 (should equal 0)
2008 1 (should equal 1)
2100 0 (should equal 0)
2400 1 (should equal 1)
2800 1 (should equal 1)

Uses

In 2008, the {{ordinal date}} template will be "one-off". Maybe we can use isLeapYear to fix this problem in advance. --Uncle Ed 15:02, 27 April 2006 (UTC)[reply]

{{#expr: {{ordinal date}} + {{isLeapYear}} }} = 311
310

tighter code?

It looks like this expression can be shortened (e.g.)

CURRENTYEAR {{ #expr: ({{CURRENTYEAR}} mod 4 = 0) and (({{CURRENTYEAR}} mod 100 = 0) or ({{CURRENTYEAR}} mod 400 != 0))}}

CURRENTYEAR 1

1600 1
1700 1
1800 1
1900 1
1999 0
2000 1
2001 0
2002 0
2003 0
2004 1
2005 0
2006 0
2007 0
2008 1
2009 0
2010 0
2011 0
2012 1
2013 0
2100 1
2200 1
2300 1
2400 1
2800 1

This looks like it works and uses less cycles, though it may fail in 2800CE.

— xaosflux ^Talk 03:33, 28 April 2006 (UTC)[reply]

I added a few more test cases; your code fails for years evenly divisible by 100 (but not divisible by 400). :( If you can get it working with those tests though, feel free to update it. (It does seem to work for 2800 though). —Locke Cole • t • c 03:45, 28 April 2006 (UTC)[reply]

Thanks, will get back on this tonight, think i have a not in the wrong place. — xaosflux ^Talk 12:12, 28 April 2006 (UTC)[reply]

tighter code-try 2

In english: If the date is (divisible by 4 and not divisible by 100) or (divisble by 400) then it's a leap year. — xaosflux ^Talk 17:24, 29 April 2006 (UTC)[reply]

{{ #expr: (({{{1|{{CURRENTYEAR}}}}} mod 4 = 0) and ({{{1|{{CURRENTYEAR}}}}} mod 100 != 0)) or ({{{1|{{CURRENTYEAR}}}}} mod 400 = 0)}}

CURRENT 1

Test Data tight-2

1600 1
1700 0
1800 0
1900 0
1999 0
2000 1
2001 0
2002 0
2003 0
2004 1
2005 0
2006 0
2007 0
2008 1
2009 0
2010 0
2011 0
2012 1
2013 0
2100 0
2200 0
2300 0
2400 1
2800 1

— xaosflux ^Talk 17:15, 29 April 2006 (UTC)[reply]

Rounding integers

I'm fighting back the urge to flat revert this, but I won't. If someone else wants to, please do. But can someone explain the logic behind this recent change? I mean, as far as I know, the old version passed all the test data we've had up, so what is this "fixing" that was previously broken? Is it worth all the added calculations to have this "correction"? —Locke Cole • t • c 21:01, 3 May 2006 (UTC)[reply]

I also do not get what this edit (same as referenced by Locke) is good for. Maybe the editor could enlighten us? --Ligulem 21:21, 3 May 2006 (UTC)[reply]

I reverted to Xaosflux. Let's not fight over templates. If someone wants to create an alternate version, they should make a new template with a new name. If it's good, other contributors will incorporate it.

More to the point, this is integer arithmetic, so I don't see any need for rounding. I hope we don't have to have this template protected to stop an edit war. --Uncle Ed 21:52, 3 May 2006 (UTC)[reply]

Actually we should be discouraging "alternate versions". If we have multiple versions in use, that's additional points of failure if something is vandalized or implemented incorrectly (forking is evil and all that). Other than that, I agree whole heartedly. —Locke Cole • t • c 22:04, 3 May 2006 (UTC)[reply]

I see you're revert warring over this template too. SlimVirgin ^(talk) 00:32, 4 May 2006 (UTC)[reply]

And? I see you're a wikistalker. Where else can I expect you to show up at? —Locke Cole • t • c 00:37, 4 May 2006 (UTC)[reply]

Obviously I've got POV in my own version, but I can't see why we would need to round off a year at all? I'm in favor of reducing computations as every millisecond adds up, but not over functionality, and absolutely not over accurancy. Having a template that works for currentyear (default) or any seems preferable over forking as well. — xaosflux ^Talk 00:53, 4 May 2006 (UTC)[reply]

This is really depressing and sad. I didn't start the category:date math templates as fuel to start another edit war. God knows we have enough of these. Let's try to cooperate here, okay? :-) --Uncle Ed 12:02, 4 May 2006 (UTC)[reply]

Ditto. I think the changes may have been meant to address rounding issues with modulus division and/or the use of a Julian date as the parameter. Julian dates use decimal values for the hour/minute and have an oddity where each 'day' (singles digit) updates at noon rather than midnight. The +/- and rounding may have been meant to handle those issues (and modulus division of decimals) properly for the 12/31 to 1/1 year changeover when using a Julian date. Just a theory though - could be something else entirely. Will have to wait for Verdy to explain. --CBDunkerson 12:30, 4 May 2006 (UTC)[reply]

Oh, well when I first created the template, I assumed all inputs would be integer. I only made to serve the {{ordinal date}} template. Maybe a Julian version which handles floating point days would be good too: {{isLeapYearJulian}} okay? --Uncle Ed 12:41, 4 May 2006 (UTC)[reply]

Use mediawiki builtin function?

There was a recent change in this template that converted it to using the {{#time}} parser function. I'm copying below (with some adaptations) a discussion that occurred at Template talk:LastLeapYear, to get more feedback, and because it ended up being about this template instead. --Waldir ^talk 01:22, 2 May 2011 (UTC)[reply]

I'd like to have this work with pure arithmetics rather than recurring to other functions, though. I'll take a look at the implementation of the #time parser function. --Waldir ^talk 23:38, 30 April 2011 (UTC)[reply]

Not surprisingly, MW seems to ultimately end up pointing to php's gmdate() (after some internal formatting). I'll investigate further. --Waldir ^talk 23:59, 30 April 2011 (UTC)[reply]
Can you believe it? I followed the trail (looks like they make it hard on purpose, I must say), and ended up here:
#define timelib_is_leap(y) ((y) % 4 == 0 && ((y) % 100 != 0 || (y) % 400 == 0))
So we're back at the beginning, with the exact same code we started off with :) --Waldir ^talk 00:46, 1 May 2011 (UTC)[reply]
Btw, don't you think {{isLeapYear}}'s code would be more intuitive if we restored the previous version? --Waldir ^talk 22:39, 1 May 2011 (UTC)[reply]

I think we should use MediaWiki parser functions whenever possible, since they will be generally faster, and more concise. The algorithm is still in the documentation. I personally find {{#time:L|1 January YYYY}} very concise and clear, since I can just look up the "#time" function in the MediaWiki documentation. The ability to leverage these functions for date arithmetic has massively simplified many of the date arithmetic templates. Just my two cents. Plastikspork _―Œ^(talk) 22:48, 1 May 2011 (UTC)[reply]

In this case I can't see how this could be faster, since it's executing the exact same arithmetic operations as the template had before. The general case might be so, but in this specific case it doesn't apply, it seems. Also, it might be more concise, but it's certainly less clear, since one needs to look up the MW documentation to figure out what that does. Let's wait for other opinions. --Waldir ^talk 01:22, 2 May 2011 (UTC)[reply]